Add-Ons

Tertiary Button

A third button weight for actions that sit below Default in importance. Text-only, or text with an icon. It reads as a quieter alternative without competing for attention with the primary call-to-action. Background and border are --gray-3; text is --gray-10.

Variant

In context with the other variants

States

Usage

Simplified Typography

Three named text styles that bundle colour, size, and weight together so callers don't have to compose tokens at every site. Use them for body copy where the foundation's heading scale is too prominent.

In context

Markup

<p class="text-default">…</p>
<p class="text-muted">…</p>
<p class="text-subtle">…</p>

Tooltips Messaging

Pure-CSS tooltips via the data-tooltip attribute — no JavaScript required. Three common uses: explaining a disabled state, naming an icon-only action, and adding context to a compact label.

Markup

<!-- Disabled button: data-tooltip on the wrapper span -->
<span data-tooltip="Complete all required form inputs before saving"
      style="display: inline-block; cursor: not-allowed;">
  <button class="primary" disabled style="pointer-events: none;">Save schedule</button>
</span>

<!-- Icon-only button: data-tooltip directly on the element -->
<button class="transparent" data-tooltip="Export to CSV" aria-label="Export to CSV">
  <i class="fa-solid fa-file-arrow-down"></i>
</button>

<!-- Chip: data-tooltip directly on the element -->
<span class="chip" data-tooltip="User currently assigned to this task">Avani Barr</span>

Icon Size Utilities

Named sizes so callers say small, medium, or large rather than resolving to a specific --size-N token at the call site. Apply alongside any icon class.

The three sizes

Side-by-side comparison

Mixed icon types

The size classes work regardless of icon system — Font Awesome glyphs and the product layer's icon-* shells size identically.

Inside buttons

By default a button's icon already renders at --size-4 (medium). Use .icon-sm or .icon-lg to nudge density.

Markup

<i class="fa-solid  fa-bookmark icon-sm"></i>
<i class="fa-solid  fa-bookmark icon-md"></i>
<i class="fa-regular fa-bookmark icon-lg"></i>  <!-- regular weight at large size -->

Spacing Variables

Aliases of the foundation --size-* scale, named so developers can signal intent at the call site — --space-N for layout gaps, padding and margins; --size-N for element dimensions (icon size, font size). Same underlying values; different vocabulary.

The scale

When to use which

In code

.layout-dual    { gap: var(--space-7); }
.page-layout    { margin: var(--space-8); }
.card           { padding: var(--space-4); }

.icon-md        { width: var(--size-4); height: var(--size-4); }
h1              { --font-size-base: var(--size-9); }

Optional t-shirt aliases

When a product only ever needs a small, fixed number of values per role — three to five distinct gaps, or a single small/medium/large step for padding on every card — the numeric ten-step scale can feel like overkill at the call site. The aliases below collapse the scale into per-role xs / sm / md / lg / xl tokens so the call site reads as intent rather than a number.

Adopt them only when the product genuinely works at three-to-five values for that role. Most products use just sm / md / lg; xs and xl are there when an extra step is needed. If you find yourself reaching past xl — or wanting a sixth step — drop back to the numeric --space-N scale and don't fight the t-shirts.

In code

.toolbar  { gap: var(--gap-sm); }
.card     { padding: var(--padding-md); }
section   { margin-bottom: var(--margin-lg); }

Why?

A scale of ten numbers tells you nothing about intent. When a reviewer reads gap: var(--size-7) they have to infer that 24 px is being used as a layout gap; gap: var(--space-7) says it directly. Existing --size-* references continue to work — the aliases are a vocabulary upgrade, not a breaking change.

Naming overrides

The foundation's Naming rules set the canonical vocabulary for the One Deswik design system — full words over abbreviations (background not bg, button not btn), danger over error, info over information. Individual products or teams sometimes need to depart from this — for parity with an existing codebase, for an internal vocabulary their team already speaks, or to express a different intent at the call site. The add-ons layer is where these per-team remaps belong.

Aliases never replace the canonical token. They sit alongside it, pointing at the same value. The foundation keeps exposing --background; an addon-layer override exposes --bg as a synonym. Both work; teams that prefer the shorter form use it locally without breaking anything outside their product.

Common remap patterns

The accent pattern

The most common remap is the accent pattern. A single semantic name stands in for both the brand action colour and the info hue when they coincide. The override defines --accent-primary for the fill (button backgrounds, focus rings, link colour) and --accent-contrast for the foreground text on top of that fill.

Override

/* In addons.css — product-specific override */
:root {
  --accent-primary:  var(--active-primary);  /* foundation brand colour */
  --accent-contrast: #fff;                   /* high-contrast text on accent fill */
}

Usage at the call site

/* before — hard-coded white text */
button.primary {
  background-color: var(--active-primary);
  color: #fff;
}

/* after — accent pattern */
button.primary {
  background-color: var(--accent-primary);
  color: var(--accent-contrast);
}

The payoff is when the brand changes. Updating --accent-primary in one place flows through every button, link, and chip that uses it; the matching --accent-contrast keeps foreground text readable without auditing every color: #fff declaration scattered across the product.

Adding new add-ons

When a product team requests something that doesn't fit the foundation or the product layer, the candidate process is:

1. Confirm the request isn't already covered by an existing token or component.
2. Add the rule to src/addons.css with a short comment describing the use case.
3. Document it on this page with a self-contained example.
4. If the same add-on gets requested by a second product team, promote it into product-specific.css or the foundation.